本系列拆解企業導入 AI／Agent 時，工具明明做完了，工作卻沒有因此變好的決策現場。
Day 03：解法名稱不能代替問題定義。

專案啟動會議開始前，投影幕上已經放著封面。

RCA Agent Phase 1
AI-driven Root Cause Analysis for IT Operations

檔名是 RCA_Agent_Kickoff_Final_v3.pptx。

架構師翻到第二頁，確認第一版要接哪些資料。

「先接應用程式 Log，Infrastructure 放第二階段。」專案經理說。

「歷史 Ticket 要接，不然沒有案例可以比對。」

「監控平台呢？」

「列在後續 Scope。」

白板很快出現四個區塊：

Log Retrieval
Ticket Search
Knowledge Base
Root Cause Suggestion

資料、功能與階段都有了。唯一還沒安排的，是訪談真正處理故障的人。

使用者訪談排在隔週。會議邀請附上簡報，請值班工程師先想想「RCA Agent 應具備哪些功能」。

訪談當天，問題自然沿著這個方向走。

「做 RCA 時通常看哪些 Log？」

「要看是哪一套系統。有時錯誤也不在出問題的 Service。」

「會不會查歷史 Ticket？」

「知道該找哪個系統時會。」

架構師記下：支援多系統 Log、跨服務關聯分析、歷史案例搜尋。

「如果先列三個可能原因，會有幫助嗎？」

工程師想了一下。

「可能有。」

會議紀錄寫成：

使用者確認 Root Cause Recommendation 具備價值。

兩週後，功能清單從四項變成十一項。每一項都合理，也都符合 RCA Agent 這個名字。

測試時才出現的工作

第一版 Prototype 完成後，團隊找同一位工程師回來測試。

畫面左側可選系統與時間區間；右側列出相關 Log、歷史 Ticket，以及三個可能原因。每一項都有來源連結。

工程師貼上一段前一晚的錯誤訊息，等結果跑完後往下滑了幾次。

「它知道這個錯誤該找哪個 Team 嗎？」

「目前沒有做 Ownership Routing。」架構師說，「這一版的 Scope 是 RCA。」

「那它知道這套 Service 現在由誰維護嗎？」

「那份資料還沒有接。」

工程師把畫面關掉。

「那我還是得先去群組裡問。」

專案經理指著候選原因。

「但它已經幫你列出可能原因了。」

「我現在不是不知道可能原因。」工程師說。「我是不知道誰有權限確認，也不知道這套東西三個月前是不是已經換人接。」

這段工作不在原本十一項功能裡。

不是因為它不重要，而是它不像 RCA Agent 應該處理的事情。

名稱先替專案選了方向

會議結束後，專案經理翻出半年前的提案紀錄。原始問題只有一句：

夜班遇到不熟悉的系統異常時，經常不知道應由哪個團隊接手。確認負責人與補齊背景資訊，平均會延誤一至兩小時。

原始紀錄沒有提到 RCA，也沒有說要做 Agent。

它先被整理成「利用 AI 協助故障分析與問題定位」，最後進入提案清單時，名稱變成 RCA Agent。

名稱讓專案很快進入可執行狀態：

• 預算可以對應到 AI 專案
• 架構師知道要討論哪些資料來源
• 供應商可以介紹相近產品
• KPI 可以開始設計準確率、回應時間與使用量

這些動作沒有錯。但它們共同依附的是一個解法，而不是對現場的共同理解。

於是後續訪談的目的，也從確認值班工程師怎麼完成工作，變成確認 RCA Agent 還缺哪些功能。

Log 分散，就加 Connector。

歷史資訊難找，就接 Knowledge Base。

輸出不夠明確，就增加 Recommendation。

真正的瓶頸若是 Ownership 資料過期、交接規則不明，或 Ticket 缺少必要背景，這些發現也容易被塞回既有方案，而不是重新判斷原來的解法是否對題。

名稱越早出現，回頭的成本越高。因為調整的不只文件標題，還包括已經畫好的架構、排進計畫的 Scope、預算說明與已經對外承諾的成果。

Solution Label 不是 Problem Definition

專案名稱不是中性的標籤。

「知識助理」會把討論帶往文件、搜尋與問答；「Log Agent」會帶往資料擷取、異常偵測與摘要；「需求 Agent」則會帶往規格生成與需求分類。

這些都可能是正確解法。但在需求還沒被確認前，它們不應該先佔用問題的名字。

否則團隊很容易跳過兩件事：

• 使用者當下真正要完成的是哪一步
• 若不處理，時間、風險或交接成本到底落在哪裡

Day 2 談的是使用者不該被要求替團隊設計 Agent。Day 3 的問題再往前一步：連專案團隊自己，也不應在開始理解前就把需求寫成一個解法名稱。

Problem Gate：先寫問題，再命名方案

在需求探索結束前，可以放一個很簡單的 Gate：

文件標題不得出現 Agent、平台、系統、Dashboard 或產品名稱。

先用固定格式記錄問題：

角色
＋觸發情境
＋無法完成的工作
＋造成的成本或風險

原本的 RCA Agent，可以先改寫成：

夜班值班工程師遇到不熟悉的服務異常時，無法快速確認負責團隊與必要背景資訊，導致故障轉交平均延遲一至兩小時。

這不是為了把文件寫得更漂亮，而是讓解法仍可被比較。

在這個問題下，可能的處理方式包括：

• 維護服務與負責團隊的 Ownership 資料
• 補齊故障 Ticket 的版本、環境與服務欄位
• 依錯誤類型推薦轉交團隊
• 搜尋相似事件與過去處理紀錄
• 只在需要理解 Log 的案例中，使用 AI 協助分析

Agent 仍可能是其中一段，但不必替整個問題決定形狀。

封面後來換了，但檔名沒有

下一次會議前，簡報封面改成：

夜間故障分流與背景資訊補全
RCA Agent Proposal – Revised Scope

團隊先整理服務與維護團隊的對應關係，要求新 Ticket 必須附上版本與環境資訊，再讓模型協助找相似案例與建議轉交方向。

Root Cause Recommendation 被移到後續階段。

不過資料夾裡的檔名還是 RCA_Agent_Kickoff_Final_v3.pptx。預算代碼、專案群組與會議邀請也沒有改。

幾個月後，新加入的成員打開資料夾，第一個問題仍然是：

「這個 RCA Agent，下一步要增加什麼功能？」

上一篇：Day 02｜會議室裡，沒有人知道第一個 Agent 要做什麼
下一篇：Day 04｜Prompt 越寫越長，問題還是沒有變清楚